[00:00.000 --> 00:06.820]  I'm just here to destroy. So, it's definitely a learning curve for me, where I'm just used to
[00:06.820 --> 00:11.540]  breaking the thing down, just to break it down, versus breaking it down to actually get some
[00:11.540 --> 00:17.480]  value out of it and turn it into something cool. So, yeah, I really appreciate all the support and
[00:17.480 --> 00:24.020]  all the help so far. It's been a great journey. Outstanding, outstanding. So, we're getting close
[00:24.570 --> 00:33.680]  kind of to the start point, just a minute or two out. Again, for those joining in the actual
[00:35.780 --> 00:43.920]  Zoom webinar, there is a button down there where you can actually post questions. I encourage you
[00:43.920 --> 00:51.660]  to please do so. The goal is, is we will try to answer any questions that come up.
[00:51.660 --> 00:58.340]  If we have the answer. U-Boot's kind of an amazing topic, and none of us claim to be,
[00:58.340 --> 01:03.900]  know possibly everything out there. But we'll do our best to be able to give you some good
[01:03.900 --> 01:10.640]  feedback on your questions. Also, after this is all over, I'll be jumping over to Discord. I think
[01:10.640 --> 01:17.920]  Garrett will be there also in the IoT Village Discord in the speaker area. So, if you have any
[01:17.920 --> 01:27.360]  follow-up questions after that, please reach out to Garrett or me or Jonathan, and we'd be more
[01:27.360 --> 01:35.100]  than glad to help you out. So, we're kind of at the go point. So, I'm going to turn this all over
[01:35.100 --> 01:43.900]  to Garrett to go ahead and get started. So, it's all yours, Garrett. All right, right on. Well,
[01:43.900 --> 01:49.920]  appreciate everyone taking some time out on Saturday. I know that normally we're in Vegas
[01:49.920 --> 01:54.740]  right now. So, it would be no harm and no foul to be taking time out on a Saturday. But appreciate
[01:54.740 --> 02:03.600]  y'all, you know, taking some time and tuning in today. So, without further ado, let's get this
[02:03.600 --> 02:12.200]  party started. So, you should be able to see my screen. We're looking at the U-Boot DC28 IoT
[02:12.200 --> 02:20.100]  Village is what we're going to be going over today. So, we got a couple agenda items to go
[02:20.100 --> 02:24.580]  over real quick. You know, what is U-Boot? First off, we're going to get that out of the way.
[02:24.720 --> 02:31.040]  Then we're going to go into pin glitching, a Philips Hue device, and then potentially getting
[02:31.040 --> 02:36.660]  root on that machine. And then we're going to switch gears a little bit and go over some common
[02:36.660 --> 02:43.680]  problems with Daryl Hyland. And it's common problems related to U-Boot and how U-Boot can
[02:43.680 --> 02:51.040]  solve them. Then we're going to be rooting a Luma Wi-Fi access point. It's like a mesh Wi-Fi
[02:51.040 --> 02:59.980]  device utilizing TFTP. And then following that, we're getting faded. So, that's the agenda for
[02:59.980 --> 03:10.220]  the day. And without further ado, let's get this party rolling. So, what is U-Boot? So,
[03:10.220 --> 03:16.660]  U-Boot is basically a universal bootloader. It's loaded by the system's ROM or read-only
[03:17.640 --> 03:24.200]  memory or BIOS. And for many one of these supported devices like, you know, SD cards,
[03:24.200 --> 03:33.260]  Flash, you know, using SPI or NAND Flash. And basically, it runs a command line interface
[03:33.260 --> 03:40.840]  over a serial port. And, you know, people like us can load and boot a kernel, possibly changing any
[03:40.840 --> 03:45.160]  of the parameters in there, you know, from the default to make it do what we want to do. Kind
[03:45.160 --> 03:51.080]  of take over and give it our own instructions versus something that comes from the manufacturer.
[03:51.080 --> 03:59.120]  You're also able to read device information, read and write Flash memory, you know, download files.
[04:00.120 --> 04:07.720]  There's a lot of different things that you can do with this. And, you know, basically,
[04:07.720 --> 04:15.300]  you can choose the memory locations of the kernel and other boot information and explicitly,
[04:15.300 --> 04:19.300]  you know, tell it, hey, I want to look at this destination, and I'm going to copy this
[04:19.300 --> 04:26.700]  information. So, it's really good at extracting data and pulling that out for further analysis,
[04:26.700 --> 04:33.220]  you know, outside of that U-boot connection. So, it's loaded from Flash memory. It's often
[04:33.220 --> 04:39.760]  accessible over a serial connection. And that's what we've used today is we're using a Chakra
[04:41.320 --> 04:47.680]  utilizing UART to connect to these devices. It also comes with a limited set of commands. So,
[04:47.680 --> 04:55.800]  several commands that we're going to be going over that come with U-boot. So, moving on.
[04:57.900 --> 05:03.700]  So, ping glitch on the Philips Hue. So, that's what we're going to be doing first. I'm going
[05:03.700 --> 05:09.620]  to get out of these slides. Boring, right? Let's get out of here. So, we're going to go up to
[05:10.540 --> 05:14.760]  my other screen over here. And just to show you some of the devices
[05:15.540 --> 05:20.220]  we're working with, we got the I'm looking all around me. It's right in front of me.
[05:20.920 --> 05:26.460]  The Philips Hue. It's basically it's been stripped down. You know, I can see the underlying
[05:27.660 --> 05:33.760]  form factor here. But, you know, this thing is to connect your lights in your house. So,
[05:33.760 --> 05:37.440]  if you wanted to, you know, have a bunch of different colored lights and then control
[05:37.440 --> 05:41.300]  them from your phone, you'd buy one of these devices. So, you can imagine a lot of people
[05:41.300 --> 05:46.000]  have these in their houses. I think you can connect up to, like, 50 light bulbs with this
[05:46.000 --> 05:52.460]  thing. And then we have the Luma, which is looks like a little Wi-Fi access point or something
[05:52.460 --> 05:58.240]  like that. But it's exactly what it is. It's a mesh Wi-Fi access point. It's got Ethernet on board.
[05:58.240 --> 06:03.040]  It's got a USB. It's got a bunch of other stuff in there you can't really see because
[06:03.040 --> 06:08.140]  camera's not very clear. But that's what we're going to be breaking down today.
[06:08.140 --> 06:13.420]  So, let me get my other situation going on here.
[06:15.800 --> 06:20.340]  And first off, got to set this up. So, bear with me here.
[06:21.880 --> 06:25.720]  And if you already have questions, you know, don't hesitate. Throw them out there while I get this
[06:25.720 --> 06:37.540]  thing set up here. Okay, that's in there. Perfect. So, just get some wires out of the way. I should
[06:37.540 --> 06:43.860]  remember that choice from last time. All good. So, just to break down what is on this now.
[06:44.220 --> 06:52.000]  So, we have the UART connection over here to my Shikra using ground over here, receive and
[06:52.000 --> 06:58.560]  transmit over here. So, we're connected to some headers that are on this motherboard. Then we have
[06:58.560 --> 07:06.160]  another set of headers over here that's set up for my ground out wire. So, I have a wire that has a
[07:06.800 --> 07:12.780]  paper clip shoved in the end of it that we may be using to glitch this thing out. So, that's a little
[07:12.780 --> 07:19.240]  bit about what's on this thing. You also have the two flash chips that we're going to be looking at.
[07:19.240 --> 07:25.580]  This one down here and this other rectangular guy right here. So, those are the two chips that are
[07:25.580 --> 07:34.120]  communicating that we're going to be disrupting. So, on the left-hand side, I have a terminal
[07:34.120 --> 07:40.880]  called... software called Cool Terminal. And it's free. You can download it. It's pretty
[07:40.880 --> 07:44.800]  versatile on Mac from, you know, the few times that I've been using it here. And
[07:45.520 --> 07:50.280]  so far, so good. You can actually see when it's transmitting and receiving. You can see when it's
[07:50.280 --> 07:57.280]  connected. A lot of good detail here. So, I'm going to disconnect and I'm going to clear the data. And
[07:57.280 --> 08:01.600]  I'm also going to look at these options. So, there has been some things that we did prior to this
[08:01.600 --> 08:08.080]  call to kind of set this up for success. So, I did change the port to my USB serial because we are
[08:08.080 --> 08:18.080]  using Ashikra. I did change the baud rate to 115200. And I also changed some of the terminal
[08:18.080 --> 08:22.960]  settings so that we can actually interact with this terminal and not pull our hair out because
[08:22.960 --> 08:28.000]  you can't backspace, you can't delete, and things start getting crazy. You know, if I can't go
[08:28.000 --> 08:34.620]  backwards, then how can we go forwards? So, a few of the options I just wanted to highlight.
[08:35.600 --> 08:41.000]  So, now that that's all said and done, let's get some power to this thing. So,
[08:42.180 --> 08:46.760]  you can't see it, but I have a power strip with my,
[08:46.760 --> 08:52.700]  controlled by my foot over here. So, let me just get power to this real quick.
[08:54.960 --> 09:02.430]  Okay, so we got power there. Got to take my shoe off because I can't do it with my shoe. I totally
[09:02.430 --> 09:08.250]  forgot I have to use my toe. So, all good. We're going to connect to this thing once we get some
[09:08.250 --> 09:17.250]  power on it. And we're in. So, this is just the normal boot up of this device. We're just looking
[09:17.250 --> 09:24.750]  at it from a terminal perspective. And with this, we can already get some good information,
[09:24.750 --> 09:29.750]  good value, because we all know when things boot up, there's a lot of information that's kind of
[09:29.750 --> 09:35.710]  sprayed out there. And sometimes it's machine communication, sometimes it's detailed information
[09:35.710 --> 09:43.270]  that we can actually use and take back and, you know, learn more about this system. So, you know,
[09:43.270 --> 09:47.950]  as it boots up, I think it takes about 32 seconds. So, we're almost there. This is a seconds
[09:47.950 --> 09:56.730]  timer on the left-hand side, if that wasn't clear. So, once we get to the login, I think it's...
[09:57.710 --> 10:03.850]  So, we're here. So, here's the login prompt. I don't know the password. I tried to look it up
[10:03.850 --> 10:15.190]  and I didn't find it. Let's see. Roots admin. Just try one. All right. So, it's not working.
[10:15.210 --> 10:22.330]  Okay. So, we cannot log in at this stage. So, let's take it to the motherboard, right? So,
[10:22.330 --> 10:28.250]  I'm going to clear this out. Okay. So, we're going to start fresh. I'm going to turn the power on
[10:28.250 --> 10:38.930]  this guy. My trusty index toe. There it is. So, I'm going to clear it. And let me get my wire ready.
[10:39.890 --> 10:45.510]  Hopefully get this on the first shot here. So, clear the data. We're connected.
[10:47.490 --> 10:56.470]  Power is on. And that's the pin. Oh, I'm shaking. Oh, there it is. Perfect.
[10:56.470 --> 11:03.630]  So, we got the command line. So, if you didn't see it, it was pretty quick. But there is a pin
[11:03.630 --> 11:12.130]  that I just lightly touched and pressed against this little paper clip thing right in there. So,
[11:12.130 --> 11:18.730]  if I can keep my hand steady, it's right around there. So, that is what got us to this point.
[11:18.750 --> 11:26.330]  And what can we do here? So, a few things. We can just ask for help. I mean, where are we? Help me.
[11:26.810 --> 11:34.090]  So, we get a lot of different commands. You know, there's boot commands. There's
[11:34.090 --> 11:41.650]  echo commands. We can echo arguments to the console. We can loop, infinite loop on an address
[11:41.650 --> 11:47.630]  range. We can ping. I think there's a ping option in here. Yeah, ping. So, we can even try to
[11:47.630 --> 11:53.790]  connect to other network assets, you know, that may be able to communicate to this device if we
[11:53.790 --> 12:00.890]  want to. We can print the environment variables. We can set the environment variables, save the
[12:00.890 --> 12:07.510]  environment variables. So, we have a lot of options here. We can even boot, TFTP boot if we wanted to.
[12:07.770 --> 12:13.750]  So, a lot of different things we can see at this point. So, we're just going to print
[12:13.750 --> 12:20.210]  the environment variables and see what else is in here. So, these environment variables
[12:21.090 --> 12:28.010]  are somewhat of the command and control area of this device. So, what we change in here does affect
[12:28.010 --> 12:35.630]  the entire system and the device. So, you know, we can see the baud rate there is set to 115200,
[12:35.630 --> 12:41.410]  which is how we're able to communicate. We see some more flash boot up details with the kernel.
[12:42.090 --> 12:49.550]  We also see some... what else is in here? We got some version information,
[12:50.630 --> 12:55.490]  production information. Oh, we got an IP address. So, we got some IP information. We got a server
[12:55.490 --> 13:01.290]  IP information. A lot of information in here. Boot delay. Oh, that looks good.
[13:01.810 --> 13:07.570]  Oh, some security thing with a hash. That's probably something. Let's see. So, I'm gonna
[13:07.570 --> 13:12.870]  just... so, we don't have to do that ping glitch again. I'm just gonna set the boot delay right now
[13:12.870 --> 13:18.430]  because I don't know about you, but my head got shaky hands and I don't want to have to do that
[13:18.430 --> 13:21.850]  every single time I reboot this thing. So, we're gonna set the environment variable
[13:22.510 --> 13:27.650]  for boot delay to five seconds just to make sure that that held. We're gonna check it again
[13:28.970 --> 13:33.790]  and it's there. So, we got five seconds on that boot delay. We have to save it.
[13:33.790 --> 13:37.770]  Otherwise, it just goes away. So, we're gonna save this.
[13:39.290 --> 13:44.070]  And that's all the jibber-jabber of saving that environment. Let's just print it one more time
[13:44.070 --> 13:54.680]  for safekeeping. And boot delay is five. So, we are there. So, I'm just gonna reset.
[13:55.820 --> 14:00.400]  Let this thing boot up again, except this time we should see a boot delay.
[14:02.020 --> 14:10.920]  Ah, there it is. So, I am going to interrupt. Rude, right? So, now that we're back in,
[14:10.920 --> 14:15.280]  what else can we do with this thing? So, let's take a look around back in those environment
[14:15.280 --> 14:21.820]  variables. And the one that kind of jumped out to me was the security and this weird hash
[14:21.820 --> 14:28.700]  following it. 1984, maybe there's some type of underlying message in here, but the security
[14:28.700 --> 14:34.520]  is something we can mess with. So, let's just set the environment of security
[14:36.080 --> 14:43.240]  to nothing. And nothing can be just two single ticks. Okay. So, if I save that or set that,
[14:43.240 --> 14:54.160]  let's check it. Ah, security equals nothing. Perfect. So, we do need to make sure we save this,
[14:54.160 --> 14:58.690]  save environment. No matter what, you always have to save. So, make sure that that's
[14:59.050 --> 15:07.190]  a, you know, nailed down. And we'll just try resetting. See if that did anything for us. So,
[15:07.190 --> 15:13.550]  essentially, what the manufacturer did with this is they hard-coded the password
[15:14.210 --> 15:22.270]  into the device. Not a good idea, in my opinion. But that's what they did. And that's why we're
[15:22.270 --> 15:27.930]  able to mess with it right now. So, we did let it go past the boot delay because we want to see
[15:27.930 --> 15:33.130]  what happens when it actually boots up now. Because before, we got hit with a login prompt.
[15:33.310 --> 15:39.050]  And I didn't have the password. So, we couldn't get anywhere with that. So, as this thing kind
[15:39.050 --> 15:46.330]  of boots up, same kind of song and dance with the boot up information. You know, it's writing,
[15:46.330 --> 15:51.270]  it's opening, it's loading, it's doing all these things. And any of those environments that we've
[15:51.270 --> 15:59.290]  changed may affect, you know, this time right now. So, if we just wait a few more seconds,
[15:59.290 --> 16:09.290]  the magic of television. And we are root. So, just by eliminating that environment variable security,
[16:09.290 --> 16:16.310]  it actually cleared out the password. And that was actually the password in a hash. So, removing it
[16:16.310 --> 16:22.350]  gave us root access. So, right on. High fives, air fives, you know, because the timing. But
[16:23.030 --> 16:29.190]  air fives all around. We got this thing. So, what can we do now? Well, lots of things.
[16:29.410 --> 16:36.170]  We can start looking at the mounted drives. We can dig into the root file system. We can look
[16:36.170 --> 16:42.630]  at the kernel. A bunch of different root drives in here. The root file system data drive. Maybe
[16:42.630 --> 16:50.910]  there's some good detail in there. You know, we're clearly at the helm here. We clearly have
[16:50.910 --> 16:57.570]  the reins of this device now. You know, we can look at other information on this thing and see
[16:57.570 --> 17:03.750]  if there's more details that we can pull out of it. More user details. Maybe some hashes. Who knows?
[17:04.310 --> 17:14.470]  But we are in like Flynn here. So, any questions on that so far?
[17:15.450 --> 17:19.650]  Hey, Garrett. Yeah, looks like we have a couple questions here cropping up. So,
[17:19.650 --> 17:24.950]  Strikeout looks like he's trying to do possibly some U-boot bypass through glitching on a wise
[17:24.950 --> 17:30.190]  came out door. And this individual is asking where did you actually put the paperclip out on the chip?
[17:30.190 --> 17:31.610]  A data line?
[17:33.990 --> 17:40.410]  Yes. So, that is a great question. It is a data line. And it's in between these two
[17:41.030 --> 17:47.750]  flash chips on the... I don't know if I can get a better view of this thing. But
[17:49.210 --> 17:52.990]  that's looking terrible. So, I can't... I don't have a micro...
[17:54.870 --> 17:58.330]  I don't have a magnifier to get you a better view of this. But
[17:58.330 --> 18:04.930]  basically, there is a pin in between the two chips that is sending data.
[18:06.470 --> 18:13.670]  It's basically this pin right here. It's a little silver flat pin there. And if you look close on
[18:13.670 --> 18:19.290]  the motherboard, you can see the tracks going between those chips. You can kind of see it,
[18:19.290 --> 18:26.660]  but now it's all blurry, of course. Yeah, to kind of add to that, this is
[18:26.660 --> 18:33.960]  real quick. Often, one of the best things to do is once you've identified the flash chips
[18:33.960 --> 18:40.600]  that you're going to attempt this on, is to track down the data sheets on those.
[18:40.600 --> 18:47.000]  And from the data sheets, in this particular case, I traced out the data zero line.
[18:47.680 --> 18:55.620]  So, between those two chips, this particular glitch is a little easier timing-wise because
[18:56.320 --> 19:04.560]  the smaller chip that's toward the bottom actually has U-boot on it. The other chip
[19:04.560 --> 19:11.440]  has the kernel on it. So, the goal is to find the data line for the chip containing a kernel
[19:12.040 --> 19:19.920]  and interrupt that by taking it to ground. And the attempt there is U-boot's loaded,
[19:19.920 --> 19:24.280]  and before it has a chance to actually load the kernel or call the kernel,
[19:24.280 --> 19:30.460]  you literally take one of those data lines to ground, causing it to
[19:30.460 --> 19:35.540]  fail to read it, as Garrett was talking about and as he showed there.
[19:42.970 --> 19:47.270]  One other question here, Garrett, that is cropping up. Individual asks,
[19:47.270 --> 19:53.530]  what type of device are you using to interact with the device here via UART?
[19:53.530 --> 19:59.310]  Are you using something like a Shikra? Yeah, let me show you. I can show you what
[19:59.310 --> 20:09.570]  that is here. We got one right here to show you. So, let me kill out this thing real quick.
[20:12.450 --> 20:17.710]  So, we're going to disconnect and pull this thing right out of my laptop for you.
[20:21.300 --> 20:28.920]  Hold power. All right. So, to give you a better idea of what this thing is, it's basically just
[20:29.060 --> 20:36.960]  a little USB with a chip attached to it with several different header connections on it.
[20:37.300 --> 20:43.960]  It comes with a data sheet that kind of breaks down what these connectors are, but that's literally
[20:43.960 --> 20:49.980]  all it is. It has three cables. I don't know where my camera is. It's got three cables, one for ground,
[20:49.980 --> 20:56.720]  one for receive and transmit. So, that's how I'm connected directly to this device.
[20:56.720 --> 21:05.780]  So, hopefully that helps. But you can pick these things up off the internet. I think they're
[21:06.980 --> 21:12.780]  30 or 40 bucks. I can't remember how much they cost, but they're doable.
[21:13.740 --> 21:15.760]  And there's some other devices out there like
[21:18.440 --> 21:23.760]  Pirate. There's one called, I think, UART Pirate or something like that, or Pirate Bay. I can't
[21:23.760 --> 21:28.580]  remember what the name of it is, but there's several tools out there that do the same,
[21:28.580 --> 21:32.100]  essentially the same thing. This is just the one that we use today.
[21:34.600 --> 21:38.520]  Cool. That's, I think, the last of the cute questions that we have here. Bus
[21:38.520 --> 21:42.200]  Pirate, I think, was the word you're looking for. That's what it was, Bus Pirate.
[21:43.860 --> 21:48.380]  Oh, man. Yep. I knew it was something to do with the pirates. Pirate would be pretty good too,
[21:48.380 --> 21:56.380]  I like the ring to none. Right on. Cool. Well, let me, if that's all the questions,
[21:56.380 --> 22:05.220]  let me just get back to the slides here and move on. So, now we're going to switch gears a little
[22:05.220 --> 22:13.420]  bit. We're going to be going over some common problems with embedded devices and then using
[22:13.420 --> 22:18.720]  U-boot to solve them. So, I'm going to switch gears and pass it over to my colleague, Darryl
[22:18.720 --> 22:27.220]  Hyland, and take it away from there. Let me just stop my share. Thanks, Garrett. Let me go ahead
[22:27.220 --> 22:38.000]  and share my screen. Hopefully, everyone can see my screen. So, kind of get back to
[22:39.320 --> 22:47.880]  the actual hue. So, I went and configured this hue to kind of exhibit some of the common problem
[22:47.880 --> 22:54.860]  that you will often encounter. And I know I've hit it two or three times working on IoT gear
[22:54.860 --> 23:04.480]  in the last year or so. And I know Jonathan has also encountered it. And again, this here is just
[23:04.640 --> 23:12.820]  a standard hue. And then this here happens to be a quad UART device. I kind of like this one.
[23:12.820 --> 23:17.720]  It's a little different than the Shikra. This one actually takes four different UARTs and you can
[23:17.720 --> 23:24.300]  switch between three and a half and four volts. And it's all USB-based. So, it's kind of sweet.
[23:24.300 --> 23:30.200]  I like using that if I need multiple UARTs at the same time. Sometimes... let's go ahead and
[23:30.200 --> 23:36.760]  plug this device in. Make sure everything's going to come up here. So, again, often when you're
[23:36.760 --> 23:42.740]  encountering devices, they'll come up. And if you noticed, it had the boot delay. I put the boot
[23:42.740 --> 23:49.460]  delay on here just to avoid having the glitch again. But the ping glitch to force into a
[23:49.460 --> 23:56.040]  U-Boot console is a literally very common method. But as you see, we hit a point here where it's
[23:56.040 --> 24:04.040]  literally disabled. We no longer have a console. And this is not uncommon. You'll have a device
[24:04.040 --> 24:15.160]  where you're actually able to establish a UART connection on the device and start seeing it
[24:15.160 --> 24:20.980]  boot up. But then inevitably when it's booted up, there's literally no console whatsoever
[24:20.980 --> 24:27.760]  on that device. I've had it go up to this point. You'll see console disabled. I've seen it come up
[24:27.760 --> 24:33.520]  and not tell me console disabled, just say loading kernel. And then you see nothing after that.
[24:33.520 --> 24:40.320]  So, whether you need to use a ping glitch or they've enabled the boot delay or some method
[24:40.320 --> 24:45.640]  you can gain access to it, we're going to go ahead and go through that. And often,
[24:45.640 --> 24:54.220]  the fix for this is typically very simple. Let's see if I can catch this here. Okay.
[24:56.800 --> 25:04.360]  Actually, which is funny, that did not work for me. So, we'll see.
[25:05.340 --> 25:09.960]  This is going to be funny if this doesn't work. It wouldn't surprise me if Zoom
[25:10.920 --> 25:18.220]  caused the problem. Because, okay, we're able to get into it. So, back to those common commands
[25:18.220 --> 25:23.020]  that Garrett had mentioned, like print environment. So, we're going to come over here and print
[25:23.020 --> 25:29.380]  environment. And again, there's literally tons of environment variables. A lot of these environment
[25:29.380 --> 25:35.060]  variables are part of the boot process, like Garrett said. Some of these actually pass commands
[25:35.060 --> 25:42.640]  to the kernel. So, the kernel knows what to do as it's loaded up. And often, where you see
[25:42.640 --> 25:49.600]  alterations that need to be made, the most common one is bootargs. You'll see bootargs
[25:49.600 --> 25:56.240]  showing the configurations. But when we come over here, we see bootargs console is actually set
[25:56.240 --> 26:01.620]  normal. So, maybe it's somewhere else. But here, we found out they have another environment variable
[26:01.620 --> 26:08.260]  called standard bootargs. So, apparently, this is what's being called at some point.
[26:08.700 --> 26:17.440]  Thus, we see the null taking place in here. Sometimes, this will involve very experimental.
[26:18.060 --> 26:22.700]  First time, when I was setting this up to identify it, that's when I found out
[26:22.700 --> 26:28.320]  that this bootargs segment doesn't work. And then you need to do it some other way.
[26:28.320 --> 26:35.380]  And then turns out it was the standard bootargs. So, to go ahead and do this, again, like you did,
[26:35.380 --> 26:49.780]  you go, you set the environment, which was standard std bootargs. Something always to remember also.
[26:51.780 --> 26:56.920]  In this case, I'm going to rewrite the entire one. And we're going to set the console here.
[27:04.280 --> 27:08.960]  And look at our standard bootargs. Make sure there's not another one. You would be surprised
[27:08.960 --> 27:14.100]  how many times I've misspelled something. And it's easy to do. And what you end up doing
[27:14.600 --> 27:19.760]  is just creating another argument that isn't read by the system or used.
[27:19.980 --> 27:25.400]  So, then you boot the system. It goes, well, it didn't fix anything. What went wrong? Often,
[27:25.400 --> 27:31.080]  it's just a typo. You've seen where people have made typos up here. Here's an example.
[27:31.080 --> 27:38.100]  Security, security. That's kind of weird. So, again, that's probably a typo that took place
[27:38.100 --> 27:43.120]  there. So, at this point, we'll go ahead and go save environment variables.
[27:44.460 --> 27:49.920]  Write the environment variables back out. And then the reset command will cause the CPU to
[27:49.920 --> 27:56.720]  reset on the device from the U-boot console. So, let's see if this will actually work.
[27:57.600 --> 28:06.320]  And it's kind of amazing. Out of the number of times I've done this, more than
[28:07.620 --> 28:12.700]  three quarters of the time when the device did boot up.
[28:14.590 --> 28:23.590]  Oh, that's interesting. We seem to have a crash on the system. We had a kernel panic.
[28:24.790 --> 28:37.530]  That's interesting. So, demos do go bad. So, we will see what we have here.
[28:39.030 --> 28:44.590]  This doesn't come up. We're probably just going to move on. Typically,
[28:45.770 --> 28:51.430]  you make these changes on the system. Yep, we got another kernel panic. I'm going to take
[28:51.430 --> 29:18.290]  one more check and see what corrupted. Yeah, that's correct.
[29:19.750 --> 29:26.750]  So, we're not going to waste much time on this. And we're just going to move on. Typically,
[29:26.750 --> 29:32.610]  there may be something in here. Sometimes these things go bad. But normally, just by fixing the
[29:32.610 --> 29:37.690]  console setting, for some reason, my kernel's messed up. I'm not sure how that happened.
[29:37.690 --> 29:41.770]  Maybe from constantly rebooting this thing over and over and over.
[29:42.410 --> 29:45.890]  Maya finally said, hey, I'm not going to play anymore, corrupted something.
[29:46.170 --> 29:53.470]  But typically, when you go into the uBoot console, and you've broke into it, and you have a device
[29:53.470 --> 29:59.230]  that will not give you a console after boot up, a lot of times you can go in here and alter either
[29:59.230 --> 30:05.450]  boot args or some other reference that's used for the boot arguments that tell the kernel what
[30:05.450 --> 30:10.690]  console, what bauld rate, all those typical things, and set that, and it'll come up.
[30:10.810 --> 30:14.930]  Usually, three quarters of the time, when I've encountered this on commercial gear,
[30:14.930 --> 30:20.210]  where they've actually turned the console off trying to hide access, when I do allow it to
[30:20.210 --> 30:27.010]  boot up, it's giving me root access from the very get-go versus giving me a password prompt.
[30:27.070 --> 30:34.130]  It's giving me root access. So, again, the best way to do this is check the console settings,
[30:34.130 --> 30:42.650]  make sure they're correct, make sure they haven't turned initialization off. I've seen this
[30:42.650 --> 30:49.250]  messed with, which would cause weird things in killing consoles and stuff like that.
[30:49.930 --> 30:55.050]  But typically, nine times out of ten, it's literally going to be the console setting.
[30:55.050 --> 31:02.190]  If it's not set, often when you identify the processor that may be used in this case,
[31:02.190 --> 31:10.590]  you can do a little Google reference and identify the most common TTY setting for that. A lot of
[31:10.590 --> 31:17.830]  times it's in the data sheet and stuff like that, to identify how it is naming its primary console
[31:17.830 --> 31:24.950]  TTY. So, often data sheets, a little Google on the device or the processor in case, to be able
[31:24.950 --> 31:31.270]  to identify that, and that helps you to literally set the console where it actually needs to be.
[31:31.270 --> 31:38.470]  Unfortunately, that demo failed, even though it's worked 40 times up until today. And I will
[31:38.470 --> 31:44.750]  stop sharing and turn this over to Garrett, so he can attempt his next demo. Is there any
[31:44.750 --> 31:51.750]  questions related to this particular failure? Let's see. It looks like there's a couple folks
[31:51.750 --> 31:57.370]  that are helping to troubleshoot, and I saw one of the issues too, I think. I guess it looks like
[31:57.370 --> 32:03.110]  bootargs was double set. Also, the board equals appeared to be missing. The bootargs, I think,
[32:03.110 --> 32:07.150]  for sure, might have been one of them. The board equals might take a little troubleshooting, but
[32:07.150 --> 32:11.350]  that's a couple questions, I guess, that came up. But another... Oh, yeah, got it right there. I see
[32:11.350 --> 32:18.870]  it. Yep. Yeah. Good catch, guys. Yep. Often when you're cutting and pasting, it's very difficult
[32:18.870 --> 32:25.070]  to do that. Since I didn't define the board, that obviously called it. So, good catch out there.
[32:25.070 --> 32:32.950]  Yeah. Props to folks on Twitch as well as here in the panel as well that kind of caught that.
[32:32.950 --> 32:38.510]  But there is a couple questions that did crop up. One individual asks, how often do you find
[32:39.070 --> 32:46.310]  that IoT devices are actually using U-boot? Like, would you say about 75%, 50%?
[32:46.890 --> 32:53.970]  I'd have to say it's still probably a little higher than 50% that I engage devices that U-boot
[32:53.970 --> 33:02.690]  used. Now, if they're running the latest version of U-boot, this typical pin glitch will not work.
[33:03.010 --> 33:09.750]  So, what happens is the newer version of U-boot that is out there, if anyone is actually using it,
[33:09.750 --> 33:16.210]  is supposed to, when it can't learn, it can't load the kernel, will actually restart the U-boot
[33:16.210 --> 33:22.390]  process. So, it'll just go into an infinite loop until it can load the kernel in that case there.
[33:22.390 --> 33:27.670]  That's how they kind of started to fix this problem. I assure you there's probably attack
[33:27.670 --> 33:33.070]  methods in that case with that to get around to it. But the best fix, what we always recommend
[33:33.070 --> 33:40.230]  to most vendors on how do you solve the problem with U-boot being an issue is start using secure
[33:40.230 --> 33:49.750]  boot. That actually answers the last question that I had here was, what's the best way of
[33:49.750 --> 33:54.130]  overcoming some of these issues? And it sounds like secure boot's the best method for that.
[34:02.870 --> 34:08.570]  Yeah, I would say secure boot is the best solution to these issues that we're running through today.
[34:11.610 --> 34:16.030]  And I think we had another question just popped up here that we can kind of squeeze in before we
[34:16.030 --> 34:19.070]  move on. Because there's one more demo, is that correct, Garrett?
[34:19.310 --> 34:23.750]  Yeah, yeah, we still got one more. But yeah, more questions, the more the merrier.
[34:23.750 --> 34:28.490]  Okay, yeah. So, Asher asks, do you know why sometimes the environment variables cannot be
[34:28.490 --> 34:33.490]  modified even with root access to the U-boot console? This apparently has happened for this
[34:33.490 --> 34:42.230]  individual. The only thing I can think of off the top of my head is that the manufacturer hard
[34:42.230 --> 34:49.490]  set some of those environment variables to not allow change even at a root level. Or there's
[34:49.490 --> 34:55.090]  just some underlying permissions that, you know, even though we may feel we're root, there may be
[34:55.090 --> 35:01.810]  some hard coded just permission set there that we just can't get into. I don't know, maybe someone
[35:01.810 --> 35:07.550]  else has more to speak on that. But that's just my initial gut feeling.
[35:09.270 --> 35:14.530]  I'd have to agree with that. I actually had a device I was playing with the other day.
[35:14.530 --> 35:21.050]  And there was probably a half dozen arguments in the environment variables that when I changed
[35:21.050 --> 35:29.830]  them and saved them, they never saved nothing. So, U-boot's a funny beast. Everybody compiles
[35:29.830 --> 35:35.530]  it differently. So, the amount of features, functions, capabilities, and how it works
[35:35.530 --> 35:41.510]  is very configurable. And every vendor will compile it and use it different.
[35:41.750 --> 35:49.330]  Also, I've seen some where boot args and all of those settings are not even used by the kernel.
[35:49.730 --> 35:57.130]  That stuff is actually hard coded into some kernel configurations. So, alterations with boot
[35:57.130 --> 36:04.870]  args don't actually work, which can be problematic too when you're trying to carry out
[36:05.330 --> 36:14.470]  some level of tax. Based on that, I think what Garrett's going to demo here just shortly
[36:15.070 --> 36:22.010]  will actually open up some other possible opportunities. If you're able to break in
[36:22.670 --> 36:28.430]  to the U-boot console, some of the stuff he's going to show may be very helpful in
[36:29.110 --> 36:40.860]  gaining a level of access into the system. Awesome. Any other questions out there, John?
[36:40.860 --> 36:43.740]  I think we're kind of on the queue. I think we're good to go.
[36:43.760 --> 36:52.400]  All right. Right on. Moving on. So, next, we're going to be going over the Luma.
[36:52.400 --> 36:59.100]  The Luma is that mesh device that we were looking at. It's got a little bit more to it
[36:59.100 --> 37:06.340]  on the motherboard itself. There's just a lot more going on. It has onboard Ethernet. It's
[37:06.340 --> 37:12.380]  got a USB port. It's got several different places to connect wires. There's some headers.
[37:13.300 --> 37:19.160]  A lot of stuff going on. I think it's got a built-in Wi-Fi chip on it, possibly. I'm not sure.
[37:19.160 --> 37:25.700]  But a lot of stuff going on there. So, we're going to boot to root here real quick out of
[37:25.700 --> 37:34.820]  these slides back into the live action. Here we go. So, now I got my Luma set up here, broken down,
[37:34.820 --> 37:42.540]  ripped it apart. I've got my UART connection over here with my ground, my receive, and my transmit.
[37:42.540 --> 37:48.360]  We're all good. I have my Ethernet actually plugged in because I'm just going direct line
[37:48.360 --> 37:55.200]  to this thing. And then I also have a ground wire that you can't really see. But there is a ground
[37:55.200 --> 38:03.560]  wire soldered onto the board over here. So, the way that I did get into this thing initially was
[38:03.820 --> 38:10.160]  a pin glitch. And I'm not going to show that today. But if it's something you want to see,
[38:10.160 --> 38:17.060]  I can demo it later if we have time. But basically, this particular chip right here is the chip that
[38:17.060 --> 38:23.380]  we are compromising to break into this thing. And it's actually this pin right here, this data
[38:23.380 --> 38:29.640]  pin right over here, the second one up. I don't know if you can even see that. But there's eight
[38:29.640 --> 38:39.120]  pins around that square chip. And we're going to short the data line or the data pin on that thing.
[38:39.120 --> 38:44.040]  So, that's how we would have got into this thing. But since we already did that, the magic of
[38:44.040 --> 38:51.240]  television, we're just going to plug some power into this thing. Okay. We got power now. And a
[38:51.240 --> 39:01.400]  little bit more slack in that line. The trusty toe. Come on, toe. There it is. And we're connected.
[39:01.400 --> 39:08.520]  And there it goes. So, what's funny about Cool Term is you have these receive and transmit
[39:08.520 --> 39:13.200]  lights going on in the bottom. So, we know that we're getting data in some way somehow.
[39:14.320 --> 39:20.000]  And again, with the boot up process, a lot of information here. And obviously, we can all read
[39:20.000 --> 39:23.500]  extremely fast. That's how we're able to read everything that's going down the screen.
[39:23.900 --> 39:30.260]  No, probably not. There's ways to extract this if you wanted to. Kind of if you recorded this
[39:30.260 --> 39:35.340]  and just played it back slow. And you could be taking like screenshots as it goes through.
[39:35.340 --> 39:41.900]  There's plenty of ways to kind of extract everything that's going on here. This one actually
[39:41.900 --> 39:47.280]  takes a little bit longer to boot up than the Hue. I think just because it has more functionality
[39:47.280 --> 39:53.480]  to it. It's not just going to turn your lights blue or green or red or whatever the ambience for
[39:53.480 --> 39:59.600]  the evening happens to be. This time, it's actually going to provide internet connection.
[39:59.760 --> 40:05.660]  So, when people come over or you have parties, not so much anymore. But when we did,
[40:05.660 --> 40:10.260]  you want to have everyone be able to have internet. We got to be staying up to date on our
[40:10.800 --> 40:16.560]  socials. We got to be, you know, staying up to date on everything. So, internet is good.
[40:17.340 --> 40:20.600]  So, we may not wait for this whole thing to boot up. I think it takes about
[40:21.080 --> 40:27.420]  a couple minutes. And my patience is weak. So, as this thing kind of rounds the bend here,
[40:27.420 --> 40:32.020]  it looks like it's doing stuff with Wi-Fi. Looks like some connections were going on,
[40:32.020 --> 40:38.500]  some different channels. Let's just see what happens. Oh, okay. So, we got a login prompt.
[40:40.260 --> 40:47.760]  We can try to log in. I don't know the password, though. Let's give it a shot anyway. Login
[40:47.760 --> 40:54.720]  incorrect. So, no luck again. We're 0 for 2 there on trying to just log into these things.
[40:55.460 --> 40:59.460]  So, what can we do? We're just going to power cycle this thing.
[41:01.680 --> 41:10.120]  All right. So, clear. Clear. All right. Pinky toe in action. All right. So,
[41:10.120 --> 41:16.560]  like I said before, the, you know, how the cooking shows do it, they don't cook that whole
[41:16.560 --> 41:21.160]  turkey right in front of you. That would be crazy. But they have one already in the oven. So, that's
[41:21.160 --> 41:26.540]  kind of what happened here is I pin glitched this thing prior to this call so that I did set this
[41:26.540 --> 41:33.020]  boot delay so that I could break out of it and get in there and actually show you some stuff. So,
[41:33.020 --> 41:37.380]  similar to before, print environment variables. We can just ask for help, though. Just see what's
[41:37.380 --> 41:45.280]  different about the Luma versus the Hue. So, some slight differences. This one's not as long
[41:45.280 --> 41:51.800]  as far as the list of items that we can do. So, just kind of piggybacking on that final
[41:51.800 --> 41:56.880]  question before is, you know, U-Boot is configured differently on every device,
[41:56.880 --> 42:04.600]  or essentially it can be. So, I was even reading up on this company called Emac. I think they do,
[42:06.460 --> 42:10.740]  Skada devices. And the way that they configure U-Boot was completely different
[42:10.740 --> 42:16.380]  than another person who configured U-Boot. Because when I was looking things up on this
[42:17.780 --> 42:22.860]  stuff, I would find several different explanations. Like, well, wait a minute.
[42:22.920 --> 42:27.880]  Is this even the same thing? Like, yeah, it is. It just can be completely configured,
[42:27.880 --> 42:33.020]  you know, in several different ways. Or compiled, I guess is the right word to use.
[42:33.020 --> 42:38.420]  So, if we look at some of these things, what jumps out to me is the boot arguments, the boot
[42:38.420 --> 42:46.500]  IPQ, boot from a flash device, boot from memory, boot from a network connection using TFTP.
[42:48.340 --> 42:56.600]  Spoiler alert, maybe. We got ping, so we can actually test ping connections. Print environment,
[42:56.600 --> 43:00.420]  like we already know. Save environment, set environment, that's all there.
[43:01.480 --> 43:09.300]  Print the memory flash information. There's a TFTP boot command right there.
[43:09.380 --> 43:13.800]  Oh, and a USB boot. So, a lot of stuff. This thing has a USB onboard, so,
[43:13.800 --> 43:22.180]  you know, there's more opportunities here. So, today, let's get back into the print environment.
[43:22.180 --> 43:27.340]  Let's take a look back at this. Today, we already have set the boot delay.
[43:27.340 --> 43:34.500]  That's already done. Boot delay is set. This boot command, though, is set to that boot IPQ.
[43:34.500 --> 43:40.220]  And if you don't remember, we can just quickly look back at that boot IPQ. What the heck is that?
[43:41.360 --> 43:48.280]  So, here it is. Boot IPQ. And it's to boot from flash device. So, that's what it's set out of
[43:48.280 --> 43:53.380]  the box from the manufacturer there. So, if we get back into those environment variables,
[43:53.380 --> 44:01.200]  what else can we mess with? Let's see. So, IP address. Ah, IP address is important.
[44:01.220 --> 44:09.060]  And we also have server IP. So, what can we do with those? So, basically, this IP address,
[44:09.060 --> 44:15.520]  this Luma device does not have networking configured out of the box. So, when it turns on,
[44:15.520 --> 44:22.720]  it just has a random IP in there. And I just set it to an available IP on the network that
[44:22.720 --> 44:29.000]  isn't already being used by the Xbox or the PlayStation or the 10 Raspberry Pis or the
[44:29.720 --> 44:34.640]  N64. You know what I'm saying? All these devices out here. So, I just chose a random IP. Doesn't
[44:34.640 --> 44:44.000]  really matter. What does matter is the server IP. The server IP is going to be the TFTP server.
[44:44.460 --> 44:50.900]  So, we're gonna be using TFTP to boot this thing or to boot from TFTP.
[44:50.900 --> 45:00.300]  And that's where this extra server comes into play. So, I got my just a Ubuntu 16.04,
[45:00.300 --> 45:06.160]  just fresh ISO I just pulled down the other day. And just found a couple articles online
[45:06.160 --> 45:11.340]  on how to set up a TFTP server. It's really straightforward. You know, if I can do it,
[45:11.340 --> 45:16.700]  I'm sure anybody on the call can do it. Because it's just creating a file, setting the right
[45:16.700 --> 45:21.980]  parameters in that file, and then making sure the service is up and running. I can't tell you
[45:21.980 --> 45:28.060]  how much pain I was having literally yesterday about trying to get this thing to work. And
[45:28.060 --> 45:31.840]  literally, I didn't really change much. And it just started working again. So,
[45:31.840 --> 45:38.660]  we're gonna see how well today goes. But anyway, it looks like it's up and running. We can just
[45:38.660 --> 45:44.780]  see if this is still good to go. All the passwords, super secret. All right. So,
[45:44.780 --> 45:52.160]  we're still running as of 1529. So, right on schedule there. Cool. And if we look at the IP
[45:52.160 --> 46:02.620]  of this device, that might help, right? I have config. Let's see. So, this is 192.168.118. So,
[46:02.620 --> 46:09.880]  that's where that IP comes into play. All right. Cool. So, jumping back to this now.
[46:10.560 --> 46:19.680]  So, this boot command is set to this. We can actually override this particular boot command
[46:19.680 --> 46:25.940]  here. And these boot arguments. Sorry, there might be a neighbor calling for their cat.
[46:25.940 --> 46:31.600]  So, I've actually already gone ahead and wrote out this command just for sake of
[46:31.600 --> 46:36.000]  typoing this thing a million times. I'm just gonna copy it over.
[46:38.460 --> 46:43.460]  And if you notice, I didn't show it, actually. But if I go back to my VM,
[46:43.460 --> 46:53.540]  I have a kernel image over here that has been compiled using open WRT. So, it's this is the
[46:53.540 --> 46:59.520]  package or the image that we're gonna be calling from my TFTP server. So, I just dropped it on the
[47:00.260 --> 47:05.900]  desktop here. I have it in several locations just because I was testing. So, I think it just needs
[47:05.900 --> 47:15.300]  to be on the root drive, just accessible. So, good stuff there. And now that we're back here,
[47:15.300 --> 47:24.150]  I'm just gonna paste this command. Cool. Just like that. So, I'm using TFTP boot,
[47:24.850 --> 47:29.710]  which is one of those help arguments, if you remember. There was a TFTP boot argument that
[47:29.710 --> 47:34.970]  we could use. And then I'm telling it, which piece of memory do I want to boot from? And I
[47:34.970 --> 47:41.310]  want to boot this particular image. And then boot at this particular address in memory. So,
[47:41.310 --> 47:46.310]  that's what this command is meant to do. So, without further ado, let's see how it goes.
[47:46.310 --> 47:54.950]  Let's just hit the big red button. And right away, you can see that it's using an Ethernet device,
[47:54.950 --> 48:04.910]  eth0. So, it is connected. It's from the server, my TFTP server at 1.18. And then from our address,
[48:05.810 --> 48:11.510]  .25. So, looks like we might be in good shape here on the first go around. How about that?
[48:12.450 --> 48:17.050]  Looks like it's uncompressing the kernel image. It's booting it up. You can see the OpenWrt right
[48:17.050 --> 48:23.930]  here, if you catch it. And then it's off to the races. So, as this thing kind of boots up,
[48:23.930 --> 48:31.010]  we'll see if we got any further than that login prompt that we had before. And if you're not
[48:31.010 --> 48:38.390]  familiar with OpenWrt, it is open source. And those can also be kind of compiled a little bit
[48:38.390 --> 48:46.470]  differently depending on, you know, what you want to do with it. So, by the way, the devices,
[48:46.470 --> 48:52.970]  if you wanted to buy these devices, very cheap on eBay. You can pick them up here. Very cheap.
[48:52.970 --> 49:00.410]  Just search eBay. But this OpenWrt, it's basically just an open source project that you can compile
[49:01.050 --> 49:08.630]  different, you know, different things and connect to different devices. It's just fully customizable.
[49:09.330 --> 49:12.290]  So, that's a little bit about what's going on there.
[49:14.370 --> 49:20.290]  Let's see. So, as this thing kind of boots up, see if we just hit one of these random buttons
[49:20.290 --> 49:29.830]  over here. Boom. So, that did it. We are in a built-in shell on the Luma device. So, this
[49:29.830 --> 49:36.430]  technically is not the Luma OS. So, I want to be clear on that. We didn't just
[49:36.430 --> 49:44.270]  root the whole Luma device. What we did is we created a kind of a landing place for
[49:45.490 --> 49:51.910]  kind of like before the OS hits the ground, we created our own OS and said, hey, we want to
[49:51.910 --> 49:59.210]  boot to our OS before you even get to yours. Okay? So, that's what this is. And so, it's not the
[49:59.210 --> 50:06.130]  direct file system on the Luma. But we can still do things similar to the Hue where we can, you
[50:06.130 --> 50:10.490]  know, dig into the root file system. We can look at the kernel, the firmware. There's a lot of
[50:10.490 --> 50:16.610]  things that we can potentially get into. There's several different techniques to do that. One of
[50:16.610 --> 50:23.470]  them would be mounting these drives. So, assuming that we had full permission, then we would just
[50:23.470 --> 50:30.110]  mount these drives and start extracting data from there. If we don't, you know, in a situation where
[50:30.110 --> 50:35.510]  we don't have access, say like for right now, like we have all zeros here. So, it's possible that we
[50:35.510 --> 50:43.690]  don't have access to this right now. So, what we could do is use something like DD to extract the
[50:43.690 --> 50:50.910]  data that way. It's a command line tool or something like TFTP and just siphon the data to
[50:50.910 --> 50:58.590]  another medium and then perform, you know, additional analysis there. But as far as from
[50:58.590 --> 51:03.130]  where we are right here, there are some things that we can do. But it is kind of in this open
[51:03.130 --> 51:09.750]  WRT console now where we'd have to get a little bit creative and kind of use our noggins and
[51:11.130 --> 51:15.170]  find another path to the Luma OS. But it's possible.
[51:16.510 --> 51:22.630]  So, that's a little bit about what we got going on on this thing. We wanted to show, you know,
[51:22.630 --> 51:31.070]  booting to an OS that we compiled on the device itself. So, that's a little bit about what we got
[51:31.070 --> 51:36.810]  going on here. Any questions on how we got to this point?
[51:39.650 --> 51:47.970]  Yep. A couple questions here. Let me take a look. One individual asks, I assume all of these attacks
[51:47.970 --> 51:54.610]  require physical access. There's no way of performing this attack remotely. Is that correct?
[51:55.470 --> 52:01.370]  Yes. So, unfortunately, if you did want to, you know, start doing some war driving or something
[52:01.370 --> 52:07.090]  or mess with your family members, whatever, it's all ethical, right? You know, you would
[52:07.090 --> 52:13.090]  have to have physical access to these devices. I imagine you could get physical access one time
[52:13.090 --> 52:19.230]  and then set up some type of logic bomb or some type of, you know, hook into the device so that
[52:19.230 --> 52:25.370]  if it were online, it could call to us in some way or somehow. Probably some of the devices that have
[52:25.370 --> 52:35.710]  internet connection more so than not. But I know that I have the light bulbs from Costco. I think
[52:35.710 --> 52:42.450]  they're called... oh, man, now I'm drawing a blank on it. But it's basically the same thing as the
[52:42.450 --> 52:48.490]  Philips Hue. And it's the Costco version. I can't remember the name of it now. It's driving me nuts.
[52:48.490 --> 52:55.390]  But basically, they were on the internet, and they didn't have very much any security. And
[52:55.950 --> 53:05.690]  I was just afraid to even mess with it at that point. I'm like,
[53:05.690 --> 53:14.530]  physical access to this thing. But, you know, you never know. So, good question.
[53:16.250 --> 53:24.130]  All right. Taking a look at another question here. As far as... I think this was touched on a little
[53:24.130 --> 53:29.990]  bit earlier as well by Daryl. But how do you know which pin to take to ground when glitching?
[53:29.990 --> 53:36.090]  I know earlier we were talking about data zero, data one. But as far as testing is concerned,
[53:36.090 --> 53:41.070]  how would you know about taking which pin to ground whenever you're performing this type of
[53:41.070 --> 53:48.090]  glitching? Yeah, that's a good question. I do have the breakdown of that flash chip
[53:48.090 --> 53:54.910]  on another screen somewhere, somehow. Bear with me. Can you still see my screen? Is it still
[53:54.910 --> 54:02.950]  showing questions? Yes. Okay, give me one second and I can get that readout for you.
[54:02.990 --> 54:12.110]  But basically, it is a data line, and it is the one that we would want to break into. So,
[54:12.110 --> 54:19.030]  when you look at the data sheets for these devices, you do want to look for the data lines
[54:19.030 --> 54:26.050]  is kind of the idea in finding out where those actually exist. Let's see if I can't
[54:27.550 --> 54:38.770]  get a good shot of this. Give me one second. Okay, got that now. Let's just minimize some things.
[54:40.890 --> 54:47.250]  Okay. So, see if I can't get a better view of this device here.
[54:50.200 --> 54:56.460]  Okay. So, you can still see my screen. What I have on there now is basically the top down view
[54:56.460 --> 55:04.840]  of that exact chip. So, if I look back to the camera, this is the chip breakdown, this one
[55:04.840 --> 55:10.220]  right here. I don't know if you can see that, but the one with the little orange paint drop.
[55:11.060 --> 55:17.660]  So, that's what we're breaking down in this diagram here. If I can get my pen out. There we
[55:17.660 --> 55:26.480]  go. So, the line that we're shorting is this SO line. This SO line over here, that's the
[55:27.240 --> 55:32.720]  data line. I can't remember exactly what it stands for. Maybe Daryl remembers, but
[55:34.400 --> 55:39.360]  that's essentially what we're shorting in this example.
[55:43.530 --> 55:47.610]  Yeah, exactly. There's also an interesting question that came up. When glitching,
[55:47.610 --> 55:54.390]  would it be a little safer to use a resistor in lieu of a paper clip? There's a possibility you
[55:54.390 --> 56:00.830]  could short a 3.3 or 5 volt trace pin and burn a register. Yeah, there's always a chance.
[56:02.650 --> 56:09.470]  That's why it's very important to... I'm not against using a resistor. I mean, there is some
[56:09.470 --> 56:17.330]  value to that. If you'd have to experiment around, because obviously you want to interrupt the
[56:17.610 --> 56:24.550]  data significantly enough, and a resistor may or may not drop the voltage enough based on the
[56:24.550 --> 56:31.010]  resistor size. But in reference to doing that, again, like he's showing here, go ahead and get
[56:31.010 --> 56:36.790]  the data sheets, figure out what you're grounding out. So, literally, you don't like just smoke
[56:36.790 --> 56:42.770]  something. To randomly go into a device here and go, oh, I think I'll just start grounding stuff
[56:42.770 --> 56:50.370]  out. It's almost a guarantee that you will brick the device permanently. Now, I've had on these
[56:50.370 --> 57:01.270]  glitching attacks, probably successful. Anytime there's two chips used, where U-Boot is on one
[57:01.270 --> 57:07.290]  chip and the kernel file system is on another, I've had a hundred percent success every time
[57:07.290 --> 57:14.850]  in actually doing that. I've only had a problem on one device, and it was using... I can't remember
[57:14.850 --> 57:20.330]  the chip it was using. It was very much more high speed, so getting it at the right time was
[57:20.330 --> 57:26.450]  difficult. We never destroyed the chip, but during the attack, even though I was taking the data line
[57:26.450 --> 57:36.670]  down the ground, I ended up actually causing it to screw the U-Boot up, and it actually damaged
[57:36.670 --> 57:45.450]  the U-Boot so that the chip would not boot up anymore. It would come up actually giving you an
[57:45.450 --> 57:50.270]  error in the U-Boot. Now, how it altered part of the data in the U-Boot during this process,
[57:50.270 --> 57:57.750]  I have no clue. Maybe it did fry register in there or smoke something, but we were able to
[57:57.750 --> 58:02.270]  pull the chip and then successfully pull the entire operating system off and recover it all anyway, so
[58:04.210 --> 58:05.390]  problem solved.
[58:07.730 --> 58:16.990]  Yeah, and just to speak on that note too, I've definitely broken enough devices just tinkering
[58:16.990 --> 58:21.610]  just like that and not really looking, you know, doing the right diligence of looking at the data
[58:21.610 --> 58:26.450]  sheet, looking at what am I actually messing with. It was more like, it's how it works in the movies,
[58:26.450 --> 58:29.710]  so it's how it works in real life. You know, I'm just going to touch a bunch of stuff and
[58:29.710 --> 58:33.950]  now I'm in. So, I definitely have a bunch of devices that
[58:34.850 --> 58:39.070]  just are paperweights around, scattered around.
[58:41.090 --> 58:43.790]  Yeah, that's funny, dude.
[58:46.750 --> 58:55.950]  Good stuff. So, that is getting into the Luma and being able to boot up,
[58:55.950 --> 59:01.190]  another operating system such as OpenWrt.
[59:03.210 --> 59:10.210]  So, if those devices aren't readily available to you, like the Philips Hue and the Luma,
[59:10.210 --> 59:14.830]  things like this, or they're the ones that you use in your house and you're not trying to lose
[59:14.830 --> 59:19.810]  internet in your house, totally get that. But if you have a Pi laying around, you can do the
[59:19.810 --> 59:29.530]  exercise with a Raspberry Pi. There's several articles over the internet that you can find
[59:30.050 --> 59:36.390]  how to do this, how to set it up, what you can do with it, and it's pretty wide. So,
[59:36.390 --> 59:41.490]  this is just an example of a Raspberry Pi that we had connected, one of my colleagues set up
[59:41.490 --> 59:47.410]  for me for this demo. So, then you have Uboot going on on the right-hand side. It's doing the
[59:47.410 --> 59:55.670]  same kind of song and dance of getting into the flash memory, the kernel, and actually printing
[59:55.670 --> 01:00:00.850]  the environment variables so that we can tweak them and adjust them and then tell it what we
[01:00:00.850 --> 01:00:13.610]  wanted to do. So, it's just another example of a Raspberry Pi. Cool. So, that is all, folks. I
[01:00:13.610 --> 01:00:18.710]  really appreciate everyone who was able to join this session on a Saturday when we're not in
[01:00:18.710 --> 01:00:25.110]  Vegas. I'm assuming we're not in Vegas, but normally hungover at this time of the day and,
[01:00:25.110 --> 01:00:33.310]  you know, completely, you know, con funk is in full force. You know, I don't know what time it
[01:00:33.310 --> 01:00:39.930]  is. I don't know where I am. That's normally the status of this day for me. So, it's a little bit
[01:00:39.930 --> 01:00:45.150]  different doing this thing virtual. So, I appreciate everyone who was able to join and
[01:00:45.150 --> 01:00:52.130]  all the questions and, you know, really happy to be here. So, if you have any other questions,
[01:00:52.130 --> 01:00:57.950]  throw them out there. But that's the end of the show. Yeah, there was one more question I saw
[01:00:57.950 --> 01:01:04.290]  come in in the chat. It said, did you download someone else's build for the Luma or did you
[01:01:04.290 --> 01:01:12.570]  do it yourself? In this particular case, this build was... I actually built this a while back
[01:01:12.570 --> 01:01:23.110]  while I was doing some testing on the Luma. So, I used OpenWrt's program. This is built off an
[01:01:23.110 --> 01:01:30.090]  IPQ40 series processors, which is what the processor is on that particular Luma. And it's
[01:01:30.090 --> 01:01:37.770]  one of the chipsets that's actually supported within the OpenWrt. Now, in this particular case,
[01:01:37.770 --> 01:01:44.770]  the success of this wasn't 100%, as Garrett pointed out, that the root FS was showing
[01:01:45.590 --> 01:01:51.270]  nothing there or zero location. And the reason why that is, is because, remember, this is a
[01:01:51.270 --> 01:01:58.670]  two-chip system. And when you're building an actual firmware package, you have to build out a
[01:01:58.670 --> 01:02:11.410]  device tree. Now, most of all of the data available on OpenWrt was very well available
[01:02:11.410 --> 01:02:18.630]  dealing with one-chip environments. But the device tree for the second chip
[01:02:18.630 --> 01:02:27.770]  has not been built into this yet, which potentially made that an issue. But once you compile it
[01:02:27.770 --> 01:02:33.610]  and compile it with the right complete device tree, complete it, then what he showed with PROC
[01:02:33.610 --> 01:02:40.690]  MTD, which is the memory technology devices, kind of an abstract layer between the hardware,
[01:02:40.690 --> 01:02:46.770]  the physical flash hardware, and the other part, you can literally from those potentially
[01:02:46.770 --> 01:02:53.250]  mount those file systems up, or you can also DD them off by actually calling them directly
[01:02:53.810 --> 01:03:02.170]  through dev MTD 0 through 9 or 10, which is one of the methods. It's really easy once you get some
[01:03:02.170 --> 01:03:08.250]  kind of console, which would be the ultimate goal of bringing in a new kernel via TFTP, because you
[01:03:08.250 --> 01:03:13.690]  would come in, it would have the device tree, you would see the chips, even though they're not
[01:03:13.690 --> 01:03:19.570]  mounted up, you can easily DD all of those images off their file system, the root file system,
[01:03:19.570 --> 01:03:27.850]  and everything from a separate booted kernel like this, giving you the ability to do some offline
[01:03:29.390 --> 01:03:35.970]  binwalk and extract the data, hopefully find the root. Or inevitably, you could even,
[01:03:36.610 --> 01:03:42.610]  when you find the root, you could easily in this particular case, DD it off, explode it out,
[01:03:42.610 --> 01:03:49.490]  and then alter it, rebuild it, repack it back in, and then DD it back over that partition
[01:03:49.490 --> 01:03:55.270]  area, and then reboot the device. And in that fashion, actually change the root password.
[01:03:55.430 --> 01:04:01.170]  So this particular attack, as he addressed and talked about, will really open up a lot of new
[01:04:01.170 --> 01:04:07.830]  avenues to some hardened devices. But it all comes down to, can you get access to that UBoot console?
[01:04:09.070 --> 01:04:18.530]  And also, the presentation or the demo I ran, and the person pointed out where I missed board,
[01:04:18.530 --> 01:04:21.910]  that was correct. As soon as we jumped off and he moved on, I went ahead,
[01:04:21.910 --> 01:04:28.070]  fixed that typo, failed to copy and reboot it, and it came up to the root prompt. So
[01:04:28.070 --> 01:04:33.170]  that worked out pretty good. So good shout out to that person, was able to visually,
[01:04:33.170 --> 01:04:37.890]  quickly capture the idea that I missed that little piece. So totally cool.
[01:04:38.910 --> 01:04:45.170]  Nice. Yeah, I just wanted to add on that. Sometimes on the devices, if you can still
[01:04:45.170 --> 01:04:54.510]  see my screen, the prompt, the command prompts on the Luma is actually the name of the chip,
[01:04:54.510 --> 01:05:01.610]  the IPQ40. So sometimes you can get even more details from just the device itself,
[01:05:01.610 --> 01:05:07.510]  just telling you like, hey, this is what I am. Hope this helps, you know. But yeah,
[01:05:07.510 --> 01:05:11.930]  I just wanted to call that out. I didn't mention it earlier, but IPQ40, like what the heck is that?
[01:05:11.930 --> 01:05:18.230]  It's the name, it's the type of chipset that's on this thing, type of processor. So
[01:05:19.750 --> 01:05:24.910]  cool. Well, really appreciate everyone, if that's all the questions.
[01:05:26.510 --> 01:05:32.290]  Not sure if there's any more, but we're good to go, right on time.
[01:05:32.710 --> 01:05:35.850]  Yeah, Jonathan, do you see anything else in the Twitch we might have missed?
[01:05:36.730 --> 01:05:41.030]  I'm taking a look here. I do see that in Zoom, someone asks, it looks like it identified the
[01:05:41.030 --> 01:05:47.050]  attached flash as well. So I guess from the U-Boot output there, it identifies the flash.
[01:05:47.490 --> 01:05:51.150]  Pulling up Twitch, I think from Twitch, we're also good to go. So the last question, I guess,
[01:05:51.150 --> 01:05:58.210]  was there and the question was, it looks like it identified the type of flash. And that might be
[01:05:58.210 --> 01:06:05.350]  kind of equally a statement as it is a question. It did. It identified the one of the flash chips.
[01:06:08.170 --> 01:06:16.270]  So could you actually from that booted kernel potentially get to those current chips?
[01:06:16.270 --> 01:06:23.910]  Yeah, it's highly possible. You may have to do some manipulation. I haven't tried it yet.
[01:06:23.910 --> 01:06:31.310]  But typically, the easiest way is to build it into the device tree for the kernel that you're
[01:06:31.310 --> 01:06:36.230]  building for that processor. That's the most effective way. Once that's built in there,
[01:06:36.230 --> 01:06:43.390]  it makes it 10 times easier for gaining access and basically altering this data or extracting
[01:06:43.390 --> 01:06:51.650]  that data off there versus not necessarily have to figure out how do I access a chip when I don't
[01:06:51.650 --> 01:07:02.030]  have a device tree for it. It's going to be very difficult. So yeah. Sorry, I had someone that was
[01:07:02.030 --> 01:07:11.930]  playing the Linkin Park at the full capacity of the volume there. So I apologize as I drove by.
[01:07:12.010 --> 01:07:17.210]  Okay, yeah, you have one person out there says you need to put that cowboy hat on behind you.
[01:07:17.410 --> 01:07:20.490]  So you look like Billy Ray Cyrus.
[01:07:27.010 --> 01:07:33.670]  Oh, y'all are cracking me up. Oh, man. I appreciate y'all. Yeah, let's see what we got.
[01:07:33.950 --> 01:07:36.650]  Here we go. Hats on.
[01:07:37.410 --> 01:07:43.910]  We have to take this off. But there we go. We're locked and loaded now.
[01:07:45.570 --> 01:07:50.030]  Pretty great. This is how you find the real bones.
[01:07:53.970 --> 01:07:55.070]  Nice.
[01:07:56.730 --> 01:08:00.910]  I mean, the people in the audience, unless the presenters need to leave,
[01:08:00.910 --> 01:08:10.690]  we still have time. There's no rush to close out quite yet. There's 30 minutes before next talk
[01:08:10.690 --> 01:08:16.210]  comes on. So we still have just a little bit of time probably we could do another five minutes
[01:08:16.210 --> 01:08:22.690]  if the presenters are still available. Hey, let me go ahead and let me go ahead and boot my
[01:08:22.690 --> 01:08:34.170]  failure. So let's switch over to that. So let me go ahead and share my screen. Let's get that going.
[01:08:37.290 --> 01:08:40.170]  Okay, hopefully everyone can see everything fine now.
[01:08:40.830 --> 01:08:43.830]  So let's go ahead and power this. Watch this thing fail again.
[01:08:44.770 --> 01:08:52.770]  I should know when to walk away to a demo failure. So let's go ahead and stop here real quick.
[01:08:52.770 --> 01:09:00.170]  Let's go print environment. So we can see what I altered. So I altered standard boot.
[01:09:00.430 --> 01:09:08.030]  When I copied it over, I missed this word right here, board equals. So it ended up specifying
[01:09:08.030 --> 01:09:14.390]  this board. And what's kind of strange is often when you do boot args, and I've mistyped things
[01:09:14.390 --> 01:09:19.810]  before, I'd never had it cause a kernel panic like that before. So it's kind of interesting.
[01:09:19.810 --> 01:09:25.750]  I've had it just skip over that functionality or whatever. So that was kind of interesting.
[01:09:26.210 --> 01:09:33.090]  So the change I did this originally said null, we're able to identify with a little legwork
[01:09:33.090 --> 01:09:39.110]  watching the system normally boot up, looking at some of that stuff, identify the type of TTY
[01:09:39.650 --> 01:10:07.570]  and replace the console null out of there. So it's common to see these options also on devices
[01:10:08.230 --> 01:10:14.570]  that are outside of the U-boot where it says press F key, enter into failsafe mode. Sometimes
[01:10:14.570 --> 01:10:20.330]  these will put you into a single user mode when the vendor's crazy enough to leave them available.
[01:10:20.330 --> 01:10:25.910]  Something to think about from when you're watching a boot option, it's not part of the U-boot stuff,
[01:10:25.910 --> 01:10:32.430]  but it can be very helpful. It will put you in a very locked down system. There won't be network,
[01:10:32.430 --> 01:10:38.890]  there won't be device drivers, there won't be nothing on there. So inherently, there you go. So
[01:10:39.450 --> 01:10:46.530]  instantly you're able to get past that. And like I said, this is kind of a common issue that you
[01:10:46.530 --> 01:10:52.770]  can run into a number of times where they've just basically said, turn the console off before you
[01:10:52.770 --> 01:10:59.550]  boot kernel or turn the console off when kernel, before kernel runs. And because of that, you don't
[01:10:59.550 --> 01:11:06.250]  get a console. If you can gain access to U-boot, probably eight out of 10 times, you can change
[01:11:06.250 --> 01:11:13.410]  those settings to be able to gain access to a console. Now, whether you'll have full root access
[01:11:13.410 --> 01:11:21.590]  after boot is to be found or figured out. But believe it or not, I think over the last so many
[01:11:21.590 --> 01:11:30.430]  years, I've encountered three or four devices that had it set up to go ahead and halt the console so
[01:11:30.430 --> 01:11:35.230]  you can have it. And when I changed the argument so the console was enabled, at least half the time,
[01:11:35.230 --> 01:11:43.210]  I had a full root console at that point. And these settings here that I mentioned,
[01:11:43.210 --> 01:11:49.150]  the press one, two, just select the debug mode. Never had much luck with those. Sometimes they
[01:11:49.150 --> 01:11:54.610]  do things, sometimes they don't. But the F key, if you ever see that, takes you to failsafe mode.
[01:11:54.610 --> 01:12:00.310]  This will give you root level access, but it's amazing how complicated with root level access
[01:12:00.310 --> 01:12:06.890]  and no ability to move data on or out of the device. It's doable, but it becomes very
[01:12:06.890 --> 01:12:11.810]  problematic because often you actually have to build the device nodes. And if they harden the
[01:12:11.810 --> 01:12:18.210]  device and turn certain programs off and remove them, it becomes more difficult. From the Luma,
[01:12:18.210 --> 01:12:24.250]  just out of curiosity from the Luma, this had this and I was working to try to get data off of it.
[01:12:24.250 --> 01:12:31.050]  In a way I originally did it was go into the F mode and actually build, manually build all the
[01:12:31.050 --> 01:12:41.350]  device, not totally manually, but very close to manually reconstruct the device nodes, naming them
[01:12:41.350 --> 01:12:47.130]  all the correct pieces and parts to build a USB. And then from there was able to move the data off
[01:12:47.130 --> 01:12:54.430]  to the USB. Just some stuff to think about. A small question just came up, Daryl. I know
[01:12:54.430 --> 01:12:59.410]  you had mentioned this yesterday during your building the IoT lab. What is your FTDI device
[01:12:59.410 --> 01:13:04.650]  you're using for that one? Its name escapes me. Someone was asking on Twitch. Oh, gosh,
[01:13:04.650 --> 01:13:09.530]  this one I have right here. Yeah, it was that cool one that could do like more than just it had like
[01:13:09.530 --> 01:13:22.240]  it supported like SPI and others in addition to UART. Yeah, that's the one. Let's power this off.
[01:13:22.320 --> 01:13:27.760]  Let's see if this has this name, has a name on it. I don't know if this even has a name. It's
[01:13:27.760 --> 01:13:34.700]  very generic and I do not even have the box for it anymore. I bought this off Amazon. All I did
[01:13:34.700 --> 01:13:44.860]  was search for multi UART connector or multi port UART connector and this came up. If I remember
[01:13:44.860 --> 01:13:55.500]  the price of this was like twenty seven dollars. But to to the life of me, I do not know the name.
[01:13:55.500 --> 01:14:03.520]  This is a generic build device coming out of China and it works pretty good. So
[01:14:04.700 --> 01:14:12.720]  cool. But sadly, I do not know what its name is or who makes it. Gotcha. Another question
[01:14:12.720 --> 01:14:19.720]  cropped up. Is there a URL or GitHub of some type where one could get ROMs to access a processor
[01:14:19.720 --> 01:14:24.420]  or access to a processor to play around with and do this type of stuff?
[01:14:26.420 --> 01:14:34.420]  I think they're asking, is there, I guess, any like I guess I think I think what's being asked
[01:14:34.420 --> 01:14:40.980]  with it is are there maybe like a list of devices that that could be purchased in order to do things
[01:14:40.980 --> 01:14:49.260]  such as U-Boot exploitation? I would actually literally exactly what Garrett said, go to
[01:14:51.360 --> 01:15:00.220]  go on to eBay and look at buying some of the devices on eBay. I think would be bright. You
[01:15:00.220 --> 01:15:07.200]  get the Lumos. You can get the you can go ahead and get the Hughes out there. He actually had
[01:15:07.320 --> 01:15:12.780]  a screen where he was showing some that were available. They're not expensive. I'm not sure
[01:15:12.780 --> 01:15:17.320]  how this would work. This is a product that that I was playing around with just recently,
[01:15:17.320 --> 01:15:24.880]  and it's like 19 or 20 bucks. And basically, it has OpenWRT running on it right now.
[01:15:24.880 --> 01:15:30.640]  It has serial connections. There's a flash chip so you can practice pulling the chip off if you
[01:15:30.640 --> 01:15:37.660]  want reading it or using SPI chip reading techniques. You can probably trace out
[01:15:38.360 --> 01:15:44.080]  versus some of these headers or connectors. You may be able to trace out the actual
[01:15:45.540 --> 01:15:53.660]  JTAGs on this for the chip. It has Ethernet. It has Wi-Fi. It has USB. And literally, it's like
[01:15:53.660 --> 01:16:01.880]  20 bucks. So this would be an easy, cheap device to possibly play with. And that's
[01:16:05.840 --> 01:16:12.840]  Vixby 300 wireless travel router. I would try playing around with that. But I have to admit,
[01:16:12.840 --> 01:16:21.200]  this was kind of footsy when it came to the actual U-boot arguments. I had a couple arguments
[01:16:21.200 --> 01:16:26.460]  that didn't work, and I couldn't alter and stuff like that. Here's another device. I think it's
[01:16:26.460 --> 01:16:32.000]  the exact same product. They're just white-labeled different. GL-iNet and Mini Smart Router also
[01:16:32.980 --> 01:16:39.840]  has all the same functions and features on it. I'm not sure if the Mango is still on the market.
[01:16:39.840 --> 01:16:48.120]  May be able to buy one used. But a lot of these cheap devices are out there,
[01:16:48.120 --> 01:16:57.500]  and it gives you a chance to experiment with UART and JTAG and SPI chips and sometimes NAND chips
[01:16:57.500 --> 01:17:05.440]  and flash chips. I mean, the list goes on and on and on, and they're often cheap. Like I said,
[01:17:05.440 --> 01:17:11.620]  Luma I like a lot because it has all of those same features, and you can get them for 20-30
[01:17:11.620 --> 01:17:21.340]  bucks used. It has the USB. It has the Ethernet. It has UART connectivity. It has NAND flash chips
[01:17:21.340 --> 01:17:31.040]  on the device. It has SOIC8 SPI flash memory chips on the device. So it's a perfect platform
[01:17:31.600 --> 01:17:37.940]  for hacking, attacking, experimenting. The pin glitch works on it also as an example.
[01:17:42.610 --> 01:17:49.390]  Awesome. I was just catching up in the chat. It was a F-E-I-T, however you pronounce that. It
[01:17:49.390 --> 01:17:55.310]  was a fight bulb that I had from Costco that I just decided to put and leave in the drawer because
[01:17:56.290 --> 01:17:58.770]  just didn't feel very secure about it.
